This is a useful section of the SearchR 2.x documentation, written be Demi.
Every computer ever made has had some method of displaying and encoding text. A computer doesn't recognize the letter 'A' in its microprocessor; everything within the computer is dealt with using hexadecimal bytes like 00, F1, and AC. In order for the computer to be able to translate these hexadecimal numbers into letters and numbers that you and I read, a conversion table is used. There will usually be 255 possible entries within a table since bytes only go up to FF (255 in decimal numbers). But, usually only about 1/2 of them are used, since alphabets hardly take up 255 slots. For IBM compatible computers, the table standard has been known as 'ASCII'.
Within the ASCII table, hexadecimal number $41 (hexadecimal numbers are usually denoted with a $ in front of them) represents the letter 'A'. From then on, $42 stands for 'B', $43 for 'C', etc... up to 'Z'. The lower case letters start at $61 ($61 for 'a'). Also, the characters '0..9' are represented by $30 to $39. The other bytes consist of less common characters such as the 1/2 symbol (½), the copyright symbol (©), and the asterisk (*). Also, some of them are used for control codes like $07, which is reserved for the system beep you hear when you turn on your computer.
Not all computers use the ASCII standard. The Macintosh does not use the ASCII standard, and neither do gaming consoles. this is where consoles are such a pain in the ass - almost none of them use the ASCII standard for their lettering and to make it worse, there is no standard amongst console systems. I could be editing CastleVania today and Final Fantasy tomorrow and I'd have to find out separate tables for both of them.
If you had to visualize what SearchR does, imagine it like this: the table is the top most row with the numbers on it. let's pretend it stetches all the way from $00 to $FF. What SearchR will do is take your string and match it to all 255 possible combinations of alphabets. in a sense, it'll slide the alphabet along the entire 255 possibilities and report the matches.
[00 01 02 03 04 05 06 07 08 09 0A 0B .. F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
[A B C .. X Y Z]
What SearchR does is it will take a word you give it that you know is going to appear somewhere in your file or ROM, and search all 255 possible combinations of that word until it finds some matches. It searches by assuming that if the letter A is for example entry $00, then B must be entry $01, and so on. it does this all relatively with variables; first it assumes letter a is $00 and searches the file for your word using that table index, reports the matches, and then moves on to assume letter A is entry 01 and letter B is entry 02. SearchR will do this repeatedly all the way up until letter A is all the way up at the end of the table index. so simply put, you have searched the file using all possible table combinations.